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Do you ever wake up on these cold chilly 
winter mornings wishing that the sun would 
come out. Winter in Wyoming seems as if it is 
never going to end. I daydream about a nice 
long walk in the summer sunshine and enjoying 
the trees, plants, and flowers along the way. 


For a VR walk through a park, be sure to check 
out A Demo World for Motion. At this point 
in time we can’t reproduce all of the feelings of 
walking through a park, but we can simulate 
walking and riding a bike. In this issue of 
PCVR, motion is our main theme and we have a 
few hints about adding these devices to your 
worlds. To achieve a greater sense of immer- 
sion, read Interfacing a Motion Device, Using 
a Treadmill for Motion, and Using a Joystick 
for Motion by Joseph D. Gradecki. 


Don’t miss our two feature articles this month. 
Visual Perception of Spatial Information by 
John Williamson explains the theory behind 
stereoscopic vision and gives us more realistic 
objects for our worlds. A C++ Powerglove 
Driver by Mark Pflaginfg builds on the original 
PowerGlove driver code and adds some power- 
ful features for your Mattel Powerglove! 


Starting with the new year, we have a new 
glossy format. We hope you enjoy the issue and 
as always your comments and participation is 


encouraged. 


Happy Valentines Day to everyone! 


Waverly R. Gradecki 
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What's New 


VPL 


Probably the biggest news lately, has been the breakup of VPL. During the EFDPMA/CyberEdge 
Journal Virtual Reality Conference held on Decmber 1-2, 1992, George Zachary, former Sales and 
Marketing Manager with VPL, announced that VPL Research had closed it's doors. Mr. Zachary and the 
newly appointed CEO Walter Fisher had left the company. It was reported that Mr. Fisher fired or laid 
off all of the employees except one, co-founder Jean-Jacques Grimaud. According to a CyberEdge 
Journal article, Zachary stated the reasons for the closure was "VPL was over-committed to all the 
different emerging niches of virtual reality in peripherals and hardware, without actually having enough 
working capital." In addition, "our previous investors were so full of the hype created not only by VPL, 
but by the press, that they weren't willing to negotiate for a lower share price. There were protracted 
negotiations between our early investores and the potential new investors, to the point that the potential 
new investors became totally irritated and left the deal as it was about to close. Amazingly, it happened 
three times." 

In previous months, the Usenet VR group, sci.virtual-worlds, had several threads about the 
inability to contact VPL or their lack of concern about literature requests. In addition, several parties 
stated that they were unable to get warranty work finished. In the second week of December, a third 
party had agreed to service VPL's products. 

VPL has moved to the address stated below and is now an operating company headed by Mr. 
Grimaud. He has vowed to make VPL regain its position in the VR market. This apparently will be done 
with the introduction of new products. The other members of the former VPL teams are working to 
build several new companies in the VR market. 

The current address for VPL is: 


VPL Research 

3977 E. Bayshore Road 

Palo Alto, CA 94303 

415-312-0200 
PATENTS 

Along with the rumors about VPL has been talk of their patents. One report that appeared on the 
_ Sci.virtual-worlds Usenet group indicated that the patents had been transfered to a French company when 
VPL was unable to repay several millions of dollars in loans. This report has not been confirmed. 

Of particular importance is a controversial patent held by VPL that covers the use of a glove to 
control a virtual object; just as all the Powergloves are being used today. This means that VPL can stop 
anyone from using a glove for virtual manipulation of objects. Of course, mouses and other devices 
would be excluded because the patent apparently mentions the glove as the specific control device. 

We will keep you up-to-date on the VPL situation, 1% | 
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Letters To 
The Editor 





New Usenet Group 


...Also, I wanted to let you know 
about our internet newsgroup 
called alt.uu. virtual-worlds.misc 
which just got underway. It is 
part of the Usenet University 
groups, and is made up of people 
interested in learning about VR. 
We are currently discussing plans 
for a group-written VR Tool Kit 
that would be the long-term 
project for us to learn all about 
3D graphics, object management, 
VR IO devices and everything 
else related to HomeBrew VR. 
...We are trying out a new 
technique called Timemodules 
for lessons. Basically a 
tilemodule is a short ( 1/2 to 2 
hr) lesson, which contains some 
info about a topic ... and then 
details an assignment that allows 
the student to practice what they 
learned. 


Dale Newcomb, Jr. 
Naval Research Lab, DC. 


IT will be in contact with Mr. 
Newcomb about the Tilemodules. 
[f possible, we will have a new 
column in PCVR that details 
what this group of homebrewists 
are doing with VR. ED. 


IEEE VR Issue 


...a special VR issue of the IEEE 
COMPUTER GRAPHICS AND 
APPLICATIONS journal. 
Would you be interested in 
submitting an article for that 
special issue which is scheduled 
to be published January 1994? 

In addition to the possiblility of a 
"do-it-yourself" VR construction 
article, other topics of interest 
include: 


% actual virtual reality applica- _ 
tion sin architecture, medicine, 
computer aided design, financial 
analysis, computational fluid 
dynamics, entertainment, graphic 
arts, other 


Yohardware, software, systems 
and services opportunites 


Yoareas in which we need addi- 
tional information to improve the 
effectiveness of virtual reality. 


°%mwhat are some of the virtual 
reality justifications 


Yonew developments in viewing 
devices such as stereo glasses, 
helmets, and others 


“onew developments in input 
devices such as, flying mice, data 
gloves, sound and pressure units 


Yofor which applications will 
virtual reality become main- 
stream. 


“orequirements for next genera- 
tion hardware and software 


“desktop visualization 


Yovirtual conferencing and 
presentation. 


We would need the paper by 
March 1993 so that it can go 
through the usual review pro- 
cess. 


Carl Machover 

Machover Associates Corp. 
199 Main Street 

White Plains, NY 10601 
(tel) 914-949-3777 

(FAX) 914-949-3851 


This is a wonderful opportunity 
for us as well as all of our 
readers. This a recognized 
graphics journal in the research 
community. I would encourage 
all of our readers to consider 
submitting an article. ED. 


Address: 


If you have something to say to 
the editors of PCVR about an 
article or just anything, write to: 


PCVR 

1706 Sherman Hill Rd. Unit A 
Laramie, Wyoming 82070 
(tel/fax) 307 - 742 - 7675 


We also welcome information 
about special VR journal issues 
such as the IEEE journal above 
or any other event. it 
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Interfacing 
a 
Motion 


Device 


| Joseph D. Gradecki | 


'To achieve the 
full sense of 


immersion in a | 


virtual world, 


we must be able 


ito manipulate 

things... One 

important thing 

to achieve is 

movement 





circuit. 


(* achieve the full sense of 


immersion in a virtual world, we 


must be able to manipulate things 
as in our real world. One impor- 


tant thing to achieve is move- 

ment. Most of the programs 

developed for the PC have dealt 

with motion through the key- 

board. As in the racquetball 

game we are developing in the 

Working With Rend386 column, 

the ‘F’ key is used to move 

forward. This is obviously not 

how we move in the real world. 


In this 

article, we will 

discuss adding 

realistic 

motion to our 

programs 
using a simple 
hardware 


The idea here 

is to interface a 

treadmill, 

bicycle, 

Norditrac, or 

some other 

device that 

allows us to 

simulate motion in the virtual 

world. In order to perform the 

simulation, we must determine 

when a complete action has 

taken place on the motion de- 
vice. On the treadmill, the 
complete action 1s the cycle of a 
supporting roller. On a bicycle, 
the complete action is the cycle 
of one of the wheels. If we can 
measure the cycle of a wheel or 
roller, we can determine when a 


.33uf - 
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person 1s standing still, walking, 
riding, or running. 


This 1s important because the 
user will have control over their 
movements in the virtual world. 
Unlike the keyboard movement 
which 1s only single speed, a 
person on a treadmill can vary 
their walking actions by simply 
changing the speed of their 
walking. 


CIRCUIT 
Figure 1 is the schematic of an 
infrared transmitter that appeared 
in an old Radio Shack catalog. 


+9y 


S10 ohm 
. Infrared LED 





FIGURE 1 


The original cicuit called for their 
infrared LED but the circuit can 
be used with just about an 
infrared LED. This circuit pulses 
the infrared LED at a rate of 4.8 
KHz. Each of the pulses lasts 45 
milliseconds. One difficulty with 
this circuit is that it requires a 
voltage of 9V instead of 5V. 
This prevents using the power 
supply from the computer. 
However, since the motion 








sluf 1k 


Infrared | 
Receiver | ws} 


device circuits will be attached to 
other machines, it is better that 
we do not use the computer 
power. 


CONSTRUCTION 

Construction of this circuit is 
fairly straightforward. A small 
piece of perfboard is used to 
mount the components. This 
perfboard can be mounted in a 
small case with a hole for the 
infrared LED. This makes 
attachment to treadmill or other 
motion device easier. 


The infrared LED used in the 
prototype was Radio Shack 276- 
142. This package consists of an 
infrared LED and detector for 
$1.99. The 9V power source 
was taken from a wall-type 
transformer. A 9V battery could 
also be used. 


RECEIVER CIRCUIT 
The circuit that receives the 
pulses from the transmitter 1s a 





FIGURE 2 


bit more complicated. Figure 2 
is the schematic of the receiver 
circuit. 


This circuit should be built as 
the transmitter was and inserted 
in a small 3" x 4" project box 
with a hole for the infrared 
receiver. The two circuits 
operate by aligning the infrared 
LED of the transmitter with the 
infrared receiver of the receiver 
circuit. The application notes 
indicate that the operational 
distance is 4 to 5 inches. This 
can be increased with the use of 
focusing lenses. The receiver 
should be connected to the 
computer via the relay. This can 
be accomplished by using an 
input line of the 8255 chip that 
we have used for the head 
mounted display switcher in issue 
4 or the 3D sound system in 
issue 6. The easiest connection 
is through port C of the 3D 
sound system 8255 interface 
chip. A simple monitoring 
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program should be used like the 
following to calibrate the system: 


program test; 

uses crt: 

begin 

{ Assume port c is at 610 deci- 

mal } 

while not keypressed do 
writeln ( port[610] ); 

end. 


This program monitors the 
status of I/O port 610. Since 
there should not be voltage at 
any of the pins, the value re- 
corded should be 0. Attach the 
receiver to input line 0 of port C. 
Now when the circuit is operat- 
ing correctly, the value at port 
610 should be a |. To calibrate 
the system, turn the 10K potenti- 
ometer on the transmitter until a 
| 1s displayed on the computer 
screen. 


Ifa | is never displayed, check 
your connection, make 


—y 
f 





sure the LEDs are aligned prop- 
erly, and try again. 


CONCLUSION i oe , ah aa ae =e , Peed: , les 
This circuit has more uses than Eo oe ae ee 
just detecting motion on a device 
sonleeuertic, Oke polentil T | eed ced aE MR eae So fe 
use of the motion detector uses a T tow acre oe oe lea tted i onee ish 
grid. Figure 3 shows this idea. oS tt ee ee oe 
In a typical size room, transmit- 2 a oe oe oe 
ter/receiver pairs could be space d T : — Be canes a ome eee saialdad : : nares 





every 1/2 foot and aligned with 
each other using focussing a ae 
mirrors. If you constructed a RRRAAR 
pattern such as that in figure 3, a FIGURE 3 
secondary computer could 

monitor the movements of a 

person fairly effectively. Most of 

the aligning and calibration 

problems could be eliminated by 

using a static frame in the shape 

of a square or whatever the 

shape of the room. This is the 

same principle as the department 

stores have that signal when a 

person enters or exits the store. 

Stay tuned as we may investigate 

this type of motion detector. !% 
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A 
Demo 
World 


for 
Motion 


Joseph D. Gradecki 





| We discuss a 
lsimple world 
| created for : 
/REND386 that | 
[can be used in 
[the three 

| demonstration 
| programs 
described in 

| the following 
articles 
















QO. discussion of motion 
would not be complete without 


9 lamps for 216 polygons 


several demonstration programs. 


In this article, we discuss a 
simple world created for 
REND386 that can be used in 
the three demonstration pro- 
grams described in the articles 
following this one. 


The idea behind this motion 
world was to create a simple 
park with trees, attractions, and 
sidewalks. This gives us places 
to walk. Figure 1 shows the 
layout of the park. 


| epcot structure for 96 polygons 
5 polyobjects for 5 polygons 


The entire park consists of 1324 
polygons and is very slow to 
render even on a 50 Mhz 80486. 
Of course, there are places in the 
park that are rendered very fast 
because the majority of the large 
objects are clipped from the view 
of the user. This world will be 
used in the following three 
articles. it 


This simple park consists of the 


following objects: 
34 trees for 751 polygons 


64 blocks for 256polygons 
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transmitter somewhere in back of 
the roller and the receiver in 


: W. have a circuit to detect front. 
Using | motion and a world to move As the roller turns, the infrared 
around in. The next step is to LED and detector will register a 
a attach the interface to something connection each time an open 
Treadmill and write the sofware. This section of the roller appears. 
article will deal with using the Because the speed of the roller is 
for interface with some mechanical fast, you will want to cover all of 
! device such as a treadmill or a the open spaces except one. 
Motion bicycle. After we discuss the Thus each time a connection is 
attachment, we will look at registered, we know that the 
interpreting the data it gives us. roller has completed one single 
revolution. Otherwise we would 
ATTACHMENT need to perform a division to 


The first step towards providing determine a single revolution and 
motion in our worlds is to attach __ it is in our best interest to manu- 


the interface to a manual tread- ally eliminate computations by 

| | mill. A bicycle could just as the computer. 

: 4 easily be substituted for the 

Joseph D. Gradecki treadmill Treadmills come in The attachment of the transmit- 

either manual or automatic form. _ ter and receiver can be tricky 
Automatic treadmills have a because we must make sure that 
motor attached to them that there are no pieces of the tread- 
forces the platform to move thus —_ mill that will catch on the boxes. 
making you move. Manual In addition, you need to take into 

— treamills have a platform of consideration the added weight 

rubber that rests on top of a of the user. How does the 


dozen or so rollers. These rollers treadmill compensate for the 
vary in size from the front of the weight. We do not want to 


This article treadmill to the back. We will smash the boxes against the floor 
: ; : use the larger rollers at the front | each time a person uses the 
will deal with | ofthe treadmill. Obviously, all __ treadmill, 
: | treadmills are different and this 
pues the , may not work for the particular In the case of a bicycle, the 
interface | one you have. In that case, easiest attachment is to use an 


check the No Slits section 
for a way to attach the 


with some 
mechanical transmitter to the rubber OPEN, 


device such of the treadmill which 
| should work for all types. 

as a treadmill | 
: Figure 1 shows want a 
il bicycle typical roller might look 


like. 





We want to attach the FIGURE 1 
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exercise bike and attach the 
boxes to each side of the forks. 
Take a piece of cardboard about 
3" x 3" and tape it to the spokes 
in the path of the LED and 
detector. Each time the card- 
board passes through the path, a 
complete revolution will be 
registered. Figure 2 shows the 
layout. 


NO SLITS 

Now, we no that all treadmills 
are not the same. Some tread- 
mills have solid rollers which will 
not work with our interface. In 
order to attach the interface to 
these treadmills, we need to take 
a look at the platform itself. This 
platform 1s usually a rubber type 
belt that simply moves across the 
rollers. 


To attach the interface to the 
rubber itself would be a feat 
because there would always be 
the possibility of stepping on the 
transmitter box. An alternative is 
to remove one of the rollers from 
either the top or bottom part of 
the treadmill and attach the 
transmitter in the rollers place. 
The receiver box would be 
attached opposite of the trans- 
mitter either to the frame of the 
treadmill or to its side. This 
doesn’t do much good because 
there would always be a connec- 
tion between the LED and 
detector. What we need to do is 
attach a piece of cardboard or 
other material to the moving 
platform. We are doing the 
reverse of the roller attachment. 
In the case of the roller, the 
connection between the LED and 
detector is normally off and 


comes on when 
the open part of 
the roller appears. 
In the case of the 
platform attach- 
ment, the connec- 
tion is normally on 
and goes off when 
the cardboard 
passes between the 
LED and detector. 
Figure 3 shows the 
idea. 


INTERPRETA- 
TION 

Now that we 
have the interface 
attached to our device, we need 
to interpret the results. The 
average person walks at a pace 
of 3 miles per hour. The pro- 
gram in CODE | (on the next 
page) can be used to translate the 
data from the interface into a 
miles per hour reading. 


This program operates by 
recording how many revolutions 
occur per a time interval of three 
seconds. This value is multiplied 
by the number of feet that passes 
each revolution of the roller. 
This value must be measured on 
your treadmill in order to be 
accurate. The multiplication 
gives us a value with units as feet 
per second. This ts multiplied by 
the conversion values for sec- 
onds per minute and minutes per 
hour to give us feet per hour. 
This is multiplied by the conver- 
sion value for feet per miles for a 
final value of miles per hour 
which 1s printed to the user. 


If this is too much information, 





FIGURE 2 


the first conversion of feet per 
second can be used. This will tell 
us exactly how much to move in 
the virtual world. 


INTEGRATION 

The last thing we need to look 
at is integration. The treadmill 
allows us to walk forward and 
backward but not diagonally. In 
order to simulate real walking, 
we need to incorporate head 
tracking. In issue 5, we dis- 
cussed the construction of a 
boom head tracker for under 
$10. That head tracker is a 
perfect companion to the bicycle 
or treadmill motion device since 
there is not much moving around 
in the real world. Thus, when 
the user turns their head and 


Transmitter 
Cardboard oon 
ee a @ 
a le @ @ 
ooole ee ics 
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starts walking, we could change 


our body position and begin 
walking in that direction in the 


virtual world. While this is not 
how we walk normally, it gives a 
better immersion sense. 





Program walktest; 
uses crt; 

convert = —; { feet per revolution } 
sec_min = 60; 

| min_hour = 60; 

mile feet = 5280; 





SOFTWARE 

On the enclosed disk, you will 
find a program called runner.c. 
This program allows you to use 


| var 
total, feet_per_sound, feet_per_hour, miles _per_hour, 
| hour, min, sec, sec2, sec10 : integer; 

begin 


the keyboard as a motion device 

through a small park. The while not keypressed do 

program should be used as a begin 

foundation for adding motion ane : hour, min, sec, secl0 ); 
total := 0; 


using the infrared interface as 


well as other devices. while ( abs(sec - sec2) <3 ) do 


{get revolutions per second} 
begin 
if (port[610] = 1 ) inc (total); 
gettime(hour, min, sec2, sec10 ); 
end; 
{Get feet per second } 
feet_per_ second := (total DIV 3) * convert; 


CONCLUSION 

We have discussed attaching an 
infrared motion detector to a 
treadmill and software that will 
interpret the data for us. Motion 
control gives the user a much 


better sense of immersion than | {Convert to feet per hour} : 
using a keyboard or other control feet_per_hour := feet_per_second * sec_min * min_hour; 
system. But for those without _ (Convert to Miles per hour } 

access to the electronics or miles_per_hour := feet_per_hour * mile feet; 

treadmill, there have to be other writeln ( “Revs = “, total, “ MPH =“, miles_per_hour ); 
mechanisms. The next article end; 

looks at using the joystick as a end. 


motion control device. if 


CODE I 
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Using 
a 
Joystick 
for 


Motion 


: Joseph D. Gradecki | 


| A joystick is a 
/natural motion 
device because | 
|most people in 
|motorized 

| wheelchairs 
have the ability 
[tomovethe | 
| chair using a 
small joystick 





Yea may be puzzled as to why 
we want to use a joystick for 
motion. One obvious use is for 
motorized wheelchairs. Most 
people in motorized wheelchairs 
have the ability to move the chair 
using a small joystick at the end 
of one of the arm rests. 


An additional motion use of the 
joystick is for an airplane. There 
may be a game there... 


This article investigates adding 
the joystick to the runner.c 
program mentioned in the previ- 
ous treadmill article. 


INITIALIZATION 

Before a joystick can be used 
with a REND386 program, we 
have to determine if one is 
available. Now obviously we 
could look around the back of 
the computer and see if a joystick 
is attached but the cleanest way 
is to ask the system itself. The 
routine joystick_check can be 
called to determine if a joystick is 
attached. The possible return 
values are 0 for no joystick, | for 
a joystick attached to port 0, 2 
for a joystick attached to port 1, 
and 3 for both joysticks attached. 
After we determine where the 
joysticks are attached, we have 
to initialize a joystick data 
structure. The REND386 
documentation gives the struc- 
ture for the joystick data struc- 
ture called joystick data. In 
order to intialize the joystick 
properly, we must declare a 
variable of this type and pass it to 
the function joystick init. 


In our program, this is done with 
the statements: 


joystick_data joy data; 


if (joy_return = joystick_check() 
popmsg ( “Joystick was not found”); 
delay (5000 ); 
exit(1); 


if (joy_return & 1) 
joystick_init ( &joy_data, 0 ); 

if (joy_return & 2) 
joystick_init ( &joy_data, 1 ); 


The variable joy_data is de- 
clared to be of type 
joystick_data. The code begins 
by determining the joystick port. 
We are assuming that only one 
joystick is being used. The 
return value of the function 
joystick_check is put into the 
variable joy_return. If the return 
value is 0, we indicate to the user 
that no joystick is available and 
exit the program. This isa 
drastic move because the pro- 
gram will still allow use of the 
keyboard. 


We then initialize the appropri- 
ate joystick by ANDing the 
return value with a bit mask. If 
the joystick is at port 0, the least- 
significant bit will be set. The 
AND will cause the if statement 
to be true and the data structure 
will be initialized for the joystick 
at port 0. If the joystick is at 
port |, the same thing will 
happen except for port 1. 


JOYSTICK READ 
Once the joystick data structure 
has been initialized, we are ready 
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to begin receiving and interpret- 
ing data from it. The function 
joystick_read takes a joystick 
data structure and fills it with 
necessary information about the 
current state of the joystick. The 
three most commonly used fields 
of this data strucutre are x, y, 
and buttons. In order to use 
these fields, we must know what 
values they are returning to us. 
To determine these values, a 
simple test program was ex- 
ecuted to read the joystick and 
report the values returned when 
the joystick is moved in all 
directions. 


A joystick is a two-dimensional 
input device. The stick can move 
forward and reverse, left and 
right. When the stick is moved 
to the farthest point left, the 
function joystick read returns a 
value of -49. When the stick is 


moved to the farthest point right, — 


the funciton returns 70. The 
value -49 is returned when the 
stick is moved forward as far as 
it can go and a value of 32 when 
the stick is moved to the back. 


As you move the stick between 
the center position and any of the 
other positions, the joystick_read 
function will return a value 
between 0 and the values dis- 

- cussed above. This allows us to 
have some control over the 
amount of movement given to a 
particular joystick position. 


For our demonstration pro- 
gram, we determine the amount 
to move in the scene by the value 
returned from the joystick_read 


function. One problem with the 
joystick is that it will not read a 
constant 0 for the x and y coordi- 
nates when you are not touching 
it. It will skip around between -8 
and 9 or so. For this reason, we 
have to set limits as to the 
usability of the information 
returned by the joystick. The 
REND386 demo program uses 
the following code: 


X = joy_data.x; 
y = joy_data.y; 


if (x>10 ) x -= 10; 


else 
{ : 
if (x >-10) x =90; 
else x += 10; 
} 
if (y>10) y -= 10; 
else 


if(y>-10) y = 0; 
else y+=10; 


3 
5 


The code begins by looking at 
the value in the x coordinate. If 
this value is greateer than 10, 10 
units are subtracted. The reason 
for this is that we are going to 
throw out anything in the range - 
10 to 10. By subtracting 10 units 
from any value greater than 10, 
we make up the values lost in the 
range. If the value is not greater 
than 10, it is checked against -10. 
If the value is in the range -10 to 
10, x is set to 0 and nothing in 
the scene changes. If the value is 
less than -10, then 10 is added to 
the value to again replace values 


inthe lost range. The code does 


the same for the y coordinate. 


Once the coordinates have been 
‘Cleaned’, we are ready to use 
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them. In the runjoy.c demo 
program, the code to use is: 


switch ( joy_data.buttons ) 


case 0: 
current_view->pan += ( x/10 * 65536L ); 
current_view->ex -=(y * thesin * 50L ); 
current_view->ez —(y * thecos * 50L ); 
redraw = 1; 
break; 


case 1: 
current_view->ex += (x * SOL * thecos); 
current_view->ez = (x * SOL * thesin); 
redraw = 1; 
break; 


} 


Since the joystick has only a 
two-dimensional base to work 
from, we have to use the buttons 
to change the function of the 
stick movement. If none of the 
buttons are down, the buttons 
field of the jostick data structure 
will be data. In our case, if no 
buttons are down, the x coordi- 
nate controls the pan of the eye. 
The y coordinate controls the 
forward and backward move- 
ment of the eye. 


If the button on top of the 
joystick stick is down, the but- 
tons field will return a value of 1. 
In this case, the x coordinate 
controls the left or right move- 
ment of the eye and the y coordi- 
nate has no function. 


Once it has been determined 
what function the coordinates 
have, the actual eye must be 
moved. In all cases, the value of 
the coordinate, either x or y, is 
used as a scaling function for the 
movement. In all of the move- 
ment cases other than pan, the 
value is multiplied by 50. Thus 





a little pressure on the joystick 
causes a little movement where 
as a lot of pressure causes a large 
movement. 


CONCLUSION 

In this article we have consid- 
ered the use of the joystick as a 
movement device. There are 
many possible virtual applica- 
tions that can be written with the 
joystick as the center device. We 
have also investigated using the 
joystick in a REND386 program. 
As the article has shown, it is a 
simple procedure to interface the 
joystick to any REND386 pro- 
gram and it adds a powerful 
feature. If 


Issue 87 January/February, 1993 PCVR 


is 


Visual 
Perception 
of 
Spatial 
Information 


John Williamson| 


| This article 
| briefly covers 
| several 


aspects of 
creating more 

| realistic 

| computer 

| images 





16 


‘Lis article (The first in a series 
of three articles. ED.) briefly 
covers several aspects of creating 
more realistic computer images. 
While a stereoscopic computer 
display (the term stereoscopic 
computer display refers to a 
system such as the SEGA 3D 
glasses and appropriate interface. 
ED) allows the addition of 
affordable stereoscopic depth 
cues to computer displays (as 
well as virtual reality hand 
gesture recognition), it should be 
noted that stereoscopic depth is 
only one of many visual depth 
cues available for computer 
graphics. It is a highly entertain- 
ing depth cue, though it is not as 
important to humans for perceiv- 
ing three dimensional space as is 
often believed. In fact, stereo- 


_ scopic depth is one of the weak- 


est of cues for determining 
depth. 


It is highly effective when the 
scene being perceived is ambigu- 
ous; as in camouflage situations. 
Furthermore stereoscopic depth 
does give fairly accurate ability 
to localize absolute depth, 
whereas most other depth cues 
give more information on relative 
depth. However, when stereo- 
scopic depth cues are presented 
in conflict with, or are tested 
against monoscopic depth cues 
(such as motion parallax, per- 
spective and interposition), 
stereoscopic depth will not fair 
well. These monoscopic cues 
will in fact override stereoscopic 
depth. To that end, and because 
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each image drawn on a computer 
is a trade-off between cost, 
computational power and time, 
this paper also includes a section 
covering other sources of visual 
depth information. This will 
allow the most effective presen- 
tation using a computer display 
with a combination of 
monoscopic and stereoscopic 
depth cues. 


Types of 3D Displays 

All stereoscopic computer 
displays work in essentially the 
same manner. The display must 
be able to present multiple views 
of an object, each drawn from a 
different view point. A minimum 
of two views are required: one 
for each eye. With the exception 
of volumetric displays, each type 
of stereoscopic display differs 
only in the medium used to 
prevent one eye from seeing the 
image intended for the other eye. 
The early stereoscopic viewers 
designed by Holmes and 
Wheatsone used prisms and 
mirrors to accomplish this 150 
years ago. 


There are three main types of 
3D display; holographic, volu- 
metric/multiplanar and 
stereopair. Holographic displays 
will not be discussed as it will be 
many years before they are 
available due to the large number 
of technical problems remaining 
to be solved (Mcallister, 1992). 
Volumetric displays may appear 
to be holographic in nature, as 
the viewer may walk around the 
image as well as look over or 
under it. It creates the illusion of 
a solid shape by rapid drawing 


“slices” of the shape on a modu- 
lating surface. These displays are 
rather large and costly and 
limited to wire-frame or translu- 
cent shapes. 


The stereo-pair is the least 
technical and the oldest of the 
techniques. There are two types 
of stereo-pair technologies 
available; the time-parallel and 
field-sequential or time-multi- 
plexed (Mcallister, 1992). In the 
time-parallel both images are 
presented at all times. This 
technique was first used in 1838 
with side by side images in the 
mirror stereoscope. It is also 
used in 3D anaglyph comic 
books and 3D movies. The field 
sequential technology used by a 
stereoscopic computer display is 
so named as only one image is 
available at a time. 


A stereoscopic computer 
display uses an “eclipse” system 
to assure that each eye sees only 
the one intended image. Each 
side of the 3D glasses alternately 
turn black and clear as the 
electricity is applied and removed 
to the liquid crystal in the lens of 
the glasses. The computer is 
wired into the glasses assuring 
that when the right eye lens is 
black and the left eye lens is 
clear, that only the left image will 
appear on the screen. The 
opposite is true when the right 
eye image is on the screen. 


The flickering is caused by the 
limitations of this system. A 
typical stereoscopic computer 
display can only draw the two 
images at ~30 frames a second. 


This translates to 15 frames a 
second for each eye. This is 
slightly below or right at a 
psychophysical threshold known 
as the “flicker fusion frequency.” 
Any sequence of still images 
flashed at a rate slower than the 
flicker fusion frequency will be 
perceived as being still images 
presented in rapid succession. A 
sequence of still images pre- 
sented faster will appear to be a 
more or less a fluent motion. 
Motion pictures are the best 
example of this phenomenon. 
Motion pictures are able to 
create the illusion of motion 
because they present a series of 
still pictures much faster than 15 
frames a second. 


The early motion pictures were 
filmed at between 13-20 frames a 
second (hand cranked movies 
resulted in significant variation). 
As this was at the flicker fusion 
frequently, these early movies 
flickered. As a result became 
known as “flicks.” 


If the stereoscopic computer 
display refresh rate were in- 
creased to 60 frames a second or 
above (as the Tektronix and 
Stereographics systems) there 
would be no flicker. However, 
this could only be brought about 
at a significantly higher financial 
cost. The flicker will usually 
seem worse if there are very 
bright or light colors used. In 
addition, the periphery of the 
human visual field is more 
susceptible to motion. Conse- 
quently, looking at the display 
out of the corner of one’s eyes 
will also make the flicker appear 


to be worse. 


As an aside, while the technol- 
ogy in a stereoscopic computer 
display is itself new, the basic 
idea is rather old. The eclipse- 
like shutter system used in the 
stereoscopic computer display 
was used to display 3D movies 
as early as 1922. Anaglyph 3D 
movies were filmed as early as 
1889 (Hutchison, 1982). There 
are a wide variety of other 
stereoscopic computer display 
technologies available. Among 
them are VISIDEP, 
Chromostero, parallax barier/ 
lenticular and over/under stereo- 
pairs. A stereoscopic computer 
display is arguably the best 
compramise between cost, ease 
of use and image quality. 


HOW TO MAKE YOUR 
OWN 3D PHOTOGRAPHS 
Though, no doubt some of the 
users of a stereoscopic computer 
display will want to display their 
own photographs on the com- 
puter monitor in 3D. To that 
end, this is a very brief tutorial 
on how to create 3D photo- 
graphs using an traditional 
camera. As mentioned above, 
two images are required. To 
obtain these two images the 
camera must be moved in be- 
tween exposures. The simplest 
method is the “astronaut shuffle.” 
So named because it was used by 
the Apollo astronauts to create 
3D pictures on the moon. The 
first picture 1s taken with the 
weight placed on the left foot, 
leaning to left. The second 
picture is taken from the same 
place, now with the weight 
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placed on the right 
foot, leaning to the 
right. This will often 
times create two level 
images separated by 
65mm. A variety of 
slide bars are available 
or can easily be con- 
structed for use ona 
tripod. Additionally, 
some people simply buy 
two inexpensive cam- 
eras, place them side by 
side and fire both 
shutter simultaneously. 


A separation of 65mm is ad- 
equate for most pictures. How- 
ever, a 30: 1 subject to camera 
ratio should be used for either 
very close (hypo-stereo) or very 
distant (hyper-stereo) subjects. 
For example, if one wished to 
photograph a city skyline that 
was 3000 meters away, in order 
for there to be any stereo effect 
the images would need to taken 
100 meters apart from each 
other. In regard to composition, 
a more interesting, and less 
demanding stereophotograph of 
the same city skyline could be 
created by placing an object in 
the foreground approximately 
180cm away from the camera 
and move the camera 65mm. 
Wide angle, 50mm or very short 
telephoto lenses are the best 
lenses to be used. Horizontal 
disparity or displacement is not 
very important, humans can 
tolerate large horizontal dispari- 
ties. Small vertical disparities 
cannot be tolerated however. An 
inexpensive carpenter’s bubble 
level can help to eliminate verti- 
cal disparity. 


Sources of Information | 


Monocular 


Static 


Accommodation Pictorial 


Dynamic 


Binocular 


Convergence Binocular 
Parallax 


Motion Kinetic 


Parallax Depth Effect 


Linear 


Perspective Gradient 


To relieve some of the inherent 
headaches with the one camera 
approach, there were a large 
variety of 35mm cameras made 
during the 1940’s and 1950’s. 
Many of these are still available 
at camera shows or through used 
camera dealers (Shutterbug, 
carries a monthly list). These 


_ cameras have at least two lenses 


allowing the two pictures to be 
taken simultaneously. All but a 
few made in the 1980’s require 
manual exposure and focus. 
However, they are remarkably 
durable and are of the highest 
quality. They are frequently 
found for under $200. 


VISUAL PERCEPTION OF 
SPATIAL INFORMATION 
“Psychology is the physics of 
virtual reality.” 

William Bricken 


There are two primary sources 
of visual information, or cues, 
used to identify and localize 
depth information, monocular 
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Size Texture Interposition Atmospheric 


Shadow Height 
Perspective 


and binocular. Monocular 
information requires only one eye 
and binocular requires two eyes. 
Monocular information includes 
static cues; accommodation, 
interposition, size, texture gradi- 
ent, linear perspective, atmo- 
spheric perspective, shading, 
height, and dynamic cues; motion 
parallax, and kinetic depth effect. 
The binocular information 
sources are convergence and 
binocular parallax. 


While each of these can serve as 
an independent source of depth 
information, they can also inter- 
act in an additive fashion (Bruno 
and Cutting 1988). In addition, 
there are times when some of 
these sources of information can 
give conflicting depth informa- 
tion. By studying these interac- 
tions, some insight into the 
temporal processing order and 
dominance can be gained. 


Also it should be noted that a 
great many of these sources of 
information are closely related. 
Elevation, size, texture gradient 
and linear perspective are very 


similar and can be drawn from 
the same set of geometric formu- 
las. Atmospheric perspective is 
viewed by some to be a type of 
interposition. 


Some researchers have studied 
these visual depth cues in blind 
children and in sighted individu- 
als using vibrotactile feedback 
devices. They have found that 
the concepts of visual spatial 
information such as interposition, 
linear perspective and size can be 
taught to congenitally blind 
children. In addition, blind 
subjects are able to recognize 
line length and orientation 
(Schneider, Hughes, Epstein, 
Bach, 1986), which are impor- 
tant parts of linear perspective. 
This implies that the ability to 
process spatial information may 
not need visual experience to 
develop. 


MONOCULAR SOURCES 
OF DEPTH INFORMATION 
Monocular sources of informa- 
tion can be separated into two 
simple categories, dynamic and 
static displays. The dynamic 
sources of information require 
movement of either the display 
or the viewer. The dynamic 
sources include motion parallax 
and kinetic depth effect. Static 
sources of information do not 
require movement. Static 
sources include accommodation, 
which 1s the feedback from the 
muscles used to focus the lens of 
the eye, and seven pictorial 
sources of depth information. 


Static Sources of Depth Infor- 


mation 


Accommodation 

The image on the retina is fo- 
cused by the movement of the 
eye muscles stretching and 
relaxing the lens of the eye. 
Much like the lens of a camera, 
the eye can only focus on a 
narrow plane in space. The 
thickness of this plane is a func- 
tion of distance and pupil size. 
As the object being focused on is 
brought nearer to the viewer, the 
ciliary muscles of the eye con- 
tract and the shape of lens 
changes, it becomes thicker. The 
feedback from these muscle 
contractions may be used a 
source of distance information. 
However, the effectiveness of 
this source of information is 
believed to be at best, limited. In 
any effect, accommodation could 
only be used a source of depth 
information for near objects. For 
objects which are further away 
than 2 meters, the ciliary muscles 
are completely relaxed and no 
further adjustment of the shape 
of the lens of the eye is possible. 
In addition, if the ciliary muscles 
are contracted for an extended 
period of time, they begin to 
fatigue rapidly and eye strain is 
experienced. 


Pictorial Sources of Informa- 
tion 


Interposition 

Interposition ts an effective 
source of information for deter- 
mining the relative depth of an 
object. The depth information in 
interposition is derived from one 
object concealing part of an- 


other. The object that is partially 
concealed by another is per- 
ceived to be further away from 
the viewer. The object which 1s 
concealing the other object is 
perceived as being closer. The 
perception of relative distance 
between the objects is enhanced 
with familiarity of the objects. 


The subject of interposition is 
covered in below as it relates 
often times to shadow, texture 
gradient and linear perspective. 
To briefly summarize (Wickens, 
et al, 1986) demonstrated that 
interposition is a very effective 
cue in determining proximity and 
altitude in pilot-like tasks. 
Williamson (1991) showed that 
hidden-lines drawing outperform 
wire-frame drawings in both 
speed and accuracy in a mental 
rotation task. Hidden line 
removal is a simple type of 
computer generated interposition 
drawing. 


Light and Shadow 

The effectiveness of light and 
shadow is due to a large part 
because objects traditionally 
receive illumination from above, 
the light from the sun and over- 
head lights for example. In 
addition, humans tend to inter- 
pret a scene as having only a 
singular light source from above 
(Ramachandran, 1988; Berbuam, 
Bever and Chung, 1983). 


In general, the objects or 
portions of an object which are 
nearest the light source will 
appear brighter. As an object is 
removed from the light, it grows 
darker. An object will also 
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become darker if another object, 
in between it and the light 
source, obscures some of the 
light. An object which protrudes 
above beyond another will 
partially cover the second with a 
shadow. The use of light and 
shadow ts very effective in giving 
us relative depth information and 
we are very familiar with the 
depth information it gives us. In 
fact, with only shading informa- 
tion, we are able to create the 
illusion of disks being either 
convex or concave (Blake and 
Bulthoff, 1990). 


Further evidence of our prefer- 
ence for light from above ts 
found tn flash photography, 
where it is recommended that the 
photographer bounce the light 
off the ceiling rather than straight 
onto the subject (Perweiler, 
1984; Brooks, 1977). This is 
done to assure that resulting 
photograph will not appear 
“flat.” In movies and theatre, 
lighting the villain’s face from 
below, rather than above, is often 
used to give them an eerie, 
“unnatural” appearance 
(Swedlund, 1974). The 3D 
effect found in buttons in Mi- 
crosoft Windows is created 
entirely with light and shadow, 
simulating an object lighted from 
above. 


Texture Gradients 

If there is pattern of equal 
density, such as the bricks ona 
patio, this pattern will grow 
systematically denser as the 
distance increases. Texture 
gradients are very closely related 
to linear perspective. The same 


geometric relationships and 
equations used to calculate the 
convergence of lines at the 
vanishing point in linear perspec- 
tive are used to draw texture 
gradients. This can be a very 
effective source of information 
for determining size and distance 
if the pattern 1s uniform and the 
objects to be judged are the same 
size. Gibson (1950) proposed 
that changes in texture gradient 
indicated edges, corners or 
spatial displacement. Further- 
more, he stated that these gradi- 
ents were processed prior to 
other shapes. 


Linear Perspective 

Linear perspective and texture 
gradient are related. The size 
and distance separating objects is 
a function of their distance from 
the viewer. The further away an 
object is the closer together its 
constituent parts will appear. 


_ The lines that often comprise the 


edges of objects will appear to 
converge to a single point di- 
rectly in front of the viewer 
called the vanishing point. Lin- 
ear perspective follows basic 
geometric principles which are 
easily included in computer 
based, three dimensional graphic 
packages. 


One of the more interesting 
studies examining perspective 
information was conducted by 
Hudson (1960). The amount of 
perspective information which a 
Westerner can use to make 
appropriate distance judgement is 
not sufficient in other cultures 
which have not been exposed to 
numerous illustrations which use 
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perspective. In this study, simple 
drawings were used which 
Westerners were able to cor- 
rectly interpret the spatial infor- 
mation presented. African 
natives were unable to do so. 


One of the pictures shown was 
of a hunter, an elephant and a 
gazelle. The hunter was depicted 
as though he was about to throw 
a spear. The elephant was drawn 
so that to a Westerner (because 
of perspective and other pictorial 
sources of information) it was 
the most distant object while the 
gazelle was in the same plane as 
the hunter. Subjects were asked 
at which animal the hunter was 
going to throw his spear. The 
Westerners stated that the hunter 
was aiming at the nearby (in the 
same depth plane) gazelle, while 
the Africans chose the elephant 
(which was closer in two dimen- 
sions to the hunter). There are 
numerous other explanations for 
the results besides a lack of 
perceptual experience. Including 
the simple fact that the question 
may have been misunderstood or 
that the Africans prefer to hunt 
elephants. These findings have 
been hotly debated in literature 
and are mentioned merely for 
discussion purposes. 


Atmospheric Perspective 
Dust, smog, fog and other 
impurities in the atmosphere 
scatter the light coming from 
objects. The further the object 
is, the more impurities come 
between it and the viewer. Asa 
result the more the light will be 
scattered and the more hazy or 
blurry the object will be. In fact, 


— 


one researcher goes so far as to 
say that atmospheric perspective 
is a type of interposition 
(Deregowski, 1984) as these 
particles partially obscure more 
distant objects. 


This results in more distant 
objects appearing blurry or hazy 
while near objects appear clear 
and focused. In addition, more 
distant objects will have a bluish 
tint. As a result, mountains may 
appear to be closer on a clear day 
than on a particular smoggy day. 
This source of information is also 
referred to a aerial perspective, 
atmospheric disparity, clearness, 
or haziness. It will also rarely be 
referred to as detail perspective, 
as objects in the distance will 
have less detail than closer 
objects. 


While consistently listed as a 
monocular source of depth 
information in nearly all refer- 
ences, little research exists which 
empirically validates the impor- 
tance of this source of informa- 
tion. Examples of paintings and 
photographs and subjective 
reports from artists as far back as 
Leonardo Da Vinci are men- 
tioned, but no empirical studies 
are ever cited (Deregowski, 
1984; Rock, 1984; Foley and 
Matlin, 1992). Irvin Rock 
(1984) goes so far as to say that 
no one to his “knowledge has 
ever shown experimentally that 
aerial perspective, in isolation, 
affects distance perception.” 
Kling and Riggs (1971) concur 
that no “systematic .. . research 
on its effectiveness has been 
pursued.” 


Elevation 

In general, the closer an object 
is to the horizon, the further 
away it is perceived. Objects 
which are higher in the visual 
field, but at or below the horizon, 
are perceived as being further 
away. This is related to linear 
perspective, and drawings which 
obey the rules of linear perspec- 
tive will subsequently display 
elevation (or height) sources of 
information. Nearer objects will 
appear further below the horizon 
closest to the bottom of our 
visual field. For objects above 
the horizon the opposite is true. 
Objects which are highest above 
the horizon will appear closer. 
Euclid, a Greek mathematician 
who formulated what came to be 
known as euclidian geometry, 
was one of the earliest to de- 
scribe elevation as a source of 
depth information (Cutting, 
1986; Boyer, 1991). 


? 


Size 

Two sources of distance infor- 
mation are related to size, rela- 
tive and familiar size. In relative 
size, if two objects of the same 
size are observed, the one which 
appears bigger that is, places a 
lager image on the retina, will 
appear closer. This was simply 
and effectively demonstrated by 
Ittleson (1951). They used two 
balloons which could be inflated 
or deflated. The subjects, ina 
darkened room, were asked to 
determine which balloon was 
closer. Both balloons were the 
same distance away, but the 
subjects consistently choose the 
bigger balloon as being closer. 


Familiar size allows us to make 
depth determinations based on 
our past experiences with an 
object. For example if we were 
shown pictures of an automobile 
we could make reasonable 
estimates as to its distance. But 
if were we to see photographs of 
an object which we were not 
familiar with, a satellite for 
example, we would not be very 
accurate in determining its 
distance. 


Familiar size has been tested in 
a variety of designs which illus- 
trate the effectiveness and 
strength of this source of infor- 
mation. Hastorf (1950) showed 
subjects a disk monocularly and 
would inform the subjects as to 
what the disk was. When sub- 
jects were told the disk was a 
ping pong ball they reported it be 
closer than when they were told 
it was billiard ball even though 
they were aware that it was a 
disk that was being presented. 


Dynamic Sources of Depth 
Information 


Motion Parallax 

When the viewer moves in 
relation to the objects being 
viewed, the perceived speed and 
direction of the objects changes 
depending upon the fixation 
point of the viewer. In general, 
the objects which are closest and 
furthest from the fixation point 
move the fastest, but in opposite 
directions. The objects nearest 
the fixation point will appear to 
move the slowest. The objects 
beyond the fixation point will 
appear to move tn the same 
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direction as the viewer, while the 
objects in front of the viewer will 
appear to move in the opposite 
direction. The further an object 
is from the fixation point, the 
faster it will appear to move. 


The degree to which we appre- 
ciate motion parallax, yet may 
not process the information 
properly is illustrated in the 
following self report “experi- 
ments” conducted by the author. 
When subjects view the 
Tektronix 3D monitor the illu- 
sion of depth is reported to be 
enhanced when they move their 
heads from side to side or walk 
around the monitor. Even 
though the motion parallax is in 
the opposite direction it would 
be if a real object were pre- 
sented. This is also true of the 
stereoscopic 3D effect when 
using a stereoscopic computer 
display. For the most part, only 
volumetric displays do not suffer 
from this illusion. 


Kinetic Depth Effect 

Kinetic movement is created 
when ever the shadow of a 
moving three-dimensional wire 
frame object is projected on a 
translucent screen. When the 
wire-frame object is rotated, the 
image 1s perceived as coming 
from a three-dimensional object. 
- When the object is stationary, the 
shadow is perceived as coming 
from a two-dimensional object. 
The series of images are per- 
ceived not as a collection of 
changing flat, two-dimensional 
patterns, but as a rotating three- 
dimensional object. 


This effect was first described 
by Wallach and O’Connell 
(1935). This is a very interesting 
and important effect, because this 
is in essence what a computer 
display does in a flight simulator 
or any similar package. 


The object being viewed is in 
motion rather than the viewer. A 
figure may appear two-dimen- 
sional or flat when it is stationary 
yet it will have volume when it 
moves (Wallach and O’Connell, 
1953). This can be illustrated by 
simply projecting a shadow ofa 
bent wire on a screen. When it is 
held stationary, it will appear flat, 
when it is rotated, it will appear 
to have depth. In part because 
some of the shadow will move 
faster than other parts. 


Another form of depth informa- 
tion from motion is the 
stereokinetic depth effect. While 


it differs from motion parallax 


and the kinetic depth effect 
which use a three-dimensional 
object projected onto a two- 
dimensional plane and is subse- 
quently perceived by the user as 
a three-dimensional object. The 
stereokinetic depth effect pre- 
sents a two-dimensional image of 
concentric, off center circles 
which are rotated on a turntable. 
The resulting perception is of 
either a truncated cone sticking 
out of the turntable or a tunnel 
receding into the turntable. 


In conclusion, while monocular, 
two-dimensional representations 
often provide sufficient informa- 
tion for reconstruction of the 
three-dimensional object, these 
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two-dimensional images often 
require “mental gymnastics” in 
order for the reconstruction to 
occur (Wickens, 1989). In 
addition, these displays are 
inherently ambiguous in specify- 
ing absolute differences and 
depths if the size of the objects 
are not known ahead of time. As 
such, a wide variety of binocular 
sources of depth information are 
also used in some computer 
displays. if 


Author 


About the Author: John Williamson is 
currently completing his Ph.D. in 
Psychology, researching the interaction 
of Gestalt organizational tendencies 
and stereoscopic depth. He is using a 
Tektronix SGS 421 stereoscopic 
monitor purchased with a grant from 
the Air Force. Main research objec- 
tives are to focus on making computer 
graphics more effective in conveying 
information using designs based on 
empirical cognitive and perceptual 
experiments. His other research 
interests include computer/human 
interaction, information design, 
complex skill acquisition and cognitive 
issues such as learning and memory. 
He has written numerous programs on 
a variety of platforms and is proficient 
in several computer languages. He is 
also completing a Hypermedia project 
on the history of stereoscopic photogra- 
phy complete with 3D illustrations. He 
also collects antique stereoimages and 
3D cameras. Texas A&M University, 
Department of Psychology, MS 
4235,Texas, 77843 (409) 845-6087. 


A 


C++ 


Powerglove 


Driver 


Mark Pflaging 


OZGLOVE is 
an object 
oriented 
driver for 
Mattel’s 
Nintendo 
Power Glove 
connected to 
the parallel 
port of a PC 





O 2GLOVE is an object 
oriented driver for Mattel’s 
Nintendo Power Glove con- 
nected to the parallel port of a 
PC. It is written in C++ for 
Borland C++ 3.1. The code has 
many features that make it 
accessible, extensible, and easy 
to incorporate into existing 
applications. First, it runs on a 
wide variety of PCs, from ‘286s 


to ‘486s, without modification, Ps 
Second, it is interrupt driven, 


which means the sampling takes 
place at regular intervals without 
requiring any attention from the 
application program. Thirdly, 
the programming interface is 
extremely simple. Since the 
program is object oriented, any 
future improvements to the 
driver would be transparent to 
the applications that use it. More 
advanced processing of the glove 
input can be handled by deriving 
classes from the main driver 
class. 


A basic explanation of how the 
power glove works 1s in order. 
The “horns” on top of the glove 
are actually speakers that emit an 
ultrasonic “clicking” that is 
detected by the L-shaped appara- 
tus, which ts just a set of three 
ultrasonic sensors. The glove 
and the sensors plug into a small 
black box that contains a micro 
controller. The micro controller 
contains a serial output mecha- 
nism that would normally be 
connected to a Nintendo Enter- 
tainment System. However, the 
connector can be rewired to a 
parallel port connector and 


plugged into a personal com- 
puter. The computer can then 
communicate directly with the 
micro controller. To be useful as 
a 3D input device suitable for 
VR work, the glove must be 
placed into hi-res mode, which 
enables the most comprehensive 
output possible from a standard 
Power Glove. Then, the com- 
puter must trigger the glove to 
perform a sample. 


Once the sample has been 
initiated by the computer, the 
glove generates an ultrasonic 
pulse, which 1s detected by the 
sensors. The microprocessor 
precisely measures the time 
between the pulse generation and 
detection, and performs calcula- 
tions to produce data that repre- 
sents the position of the glove. 
Four data elements are com- 
puted: X, Y, Z, and rotation. 
The microprocessor then trans- 
mits the four values (along with a 
byte for the buttons on the glove) 
serially to the computer. Since 
the data is conveyed serially, only 
one bit can be sent to the com- 
puter at atime. A total of five 
eight-bit values are sent. Of 
course, each eight bit value can 
be thought of as a byte. There is 
a specific delay time between 
each bit that is sent, and a differ- 
ent delay time between each 


byte. 


The file “glove.ini” within the 
distributed package contains 
settings used in the driver. The 
values are read into memory with 
the InitFile class constructor. 
The main driver class accesses 
the variables via member func- 
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tions of the InitFile class. Under- 
standing the variables in 
“slove.ini” will provide a founda- 
tion for understanding the inner 
workings of the glove driver. 
The variables are divided into 
sections by lines of the form 
“(Section name]”. Of primary 
interest are the parameters in the 
“(Timings]” section. The value 
of D2BITS (default 15) repre- 
sents the number of microsec- 
onds between each transmitted 
bit, while DZBYTES (default 
100) represents the number of 
microseconds between each 
transmitted byte. D2SLOW is a 
1 millisecond delay, which is 
used only while putting the glove 
in hi-res mode. 


In order to make the driver 
work with any computer, the 
timing loops in the heart of the 
driver need to be calibrated to 
fairly precise values. In order for 
a glove sample to be successful, 
many conditions must be met. 
Generally, it is more difficult to 
get a good sample when the 
sampling rate is increased (that 
is, fast sampling should be 
avoided). When the sampling 
rate is about 100 milliseconds, 
the D2BITS., D2BYTES, and 
D2SLOW values can be adjusted 
slightly with little or no effect. 
The class PZTimer can be used 
~ to precisely measure the amount 
of time a program spends on a 
particular task. It is used as 
follows: 





PZTimer ptimer; 
ptimer.resetQ); 

ptimer.startQ; 

// code to be timed goes here.... 
ptimer.stopQ; 

long microsecs = ptimer.countQ); 


This way, the effect of any 
modifications to the delay loop 
can be isolated. 


Apparently, there is still no way 
to provide a delay (accurate to 
the microsecond level) that 
works on any machine. Since 
O2GLOVE is designed to run on 
machines with very different 
architectures, the solution is not 
so simple. Some have instruction 
caching, some do not. Some 
have floating point processors, 
some do not. To accommodate 
the machine differences, the 
delay loop is written as shown 
below: 


- jong i; 


if (timing func) timing _funcQ; 
else { 
i= (long ) ( (Num) * val ); 
for(; i> 0; i= (Den) ); 
} 


“Num” and “Den” stand for 
Numerator and Denominator. 
As the Numerator 1s increased, 
the delay imposed by the loop 
increases. As the Denominator 
increases, the delay imposed by 
the loop decreases. “val” 1s a 
parameter that serves as a multi- 
plier for the loop. 

“timing func()” is a pointer to a 
function that would provide 
exactly the same delay as the 
delay loop. It is not currently 
used in O2GLOVE because the 
delays are so short. 
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A key point in solving the 
problem is the realization that 
Num and Den should not be the 
same for any value of “val.” On 
a 486/33, when val=D2BYTES, 
Num/Den should be about 19/16, 
and when val=D2BITS, Num/ 
Den should be 3/4. The values 
given do not increase or decrease 
proportionally with the speed of 
the machine. The solution to the 
whole problem is to “calibrate” 
Num/Den three times, and use 
the correct Num/Den for the 
“val” that is used. machineTimer 
is a class that handles these 
timing issues. The constructor of 
the class does the calibration. 
“val” 1s passed to the constructor 
and stored. Num/Den starts out 
at 1/1, and the delay loop is 
timed using the PZ Timer (de- 
scribed above). Num/Den is 
increased by 1/1 until it is too 
large, and then it is slowly 
decreased until the measured 
number of microseconds 1s 
within 10% of “val.” Now, 
finally, there are three objects 
within the program, D2BITS, 
D2BYTES, and D2SLOW, 
which have a member function 
“fdelay()” that produces a delay 
corresponding to the value listed 
in glove.ini. Num/Den can be 
specified for each of the three 
delays explicitly in glove.ini, and, 
of course, the values will not be 
computed. 


The code for actually reading a 
sample is contained in just two 
functions from hardware.cpp: 


int gloveDriver::updateGloveDataQ; 
unsigned char 


gloveDriver::get_glove_byteQ; 


In addition to accessing the 
machineTimer objects as de- 
scribed above, the functions 
make calls to the parallelPort 
class to perform the raw bit 
input/output and bit shifting in 
order to get the five bytes. The 
address of the parallel port is 
determined in the gloveDriver 
constructor and stored in the 
parallelPort class. The actual 
data 1s read directly into the 
tagGloveData structure of the 
GloveData class. This gives the 
application access to the data via 
the member functions shown 
below: 


int getX(Q); int getY(; int getZQ; 
int getRotation(; int getFingers(; 
int getKeys(; 


These are available (via inherit- 
ance) to all descendants of 
GloveData, including 
gloveDriver, cfGlove, and 
smooth. The meanings of the 
return values are explained in the 
file glovedat.hpp. Reading in the 
data from the glove is a straight- 
forward procedure once the 
timing values have been estab- 
lished. 


To sum up, the glove driver 
begins running upon instantiation 
of either cfGlove or smooth. 
Each constructor determines the 
calibration for the three impor- 
tant timing constants, and then 
tries to put the glove into hi-res 
mode. A loop in the gloveDriver 
constructor repeatedly polls three 
different parallel port addresses 
until the glove responds. Then 
the interrupt handler is installed 
by calling “SegaISR::run().” In 


addition to reprogramming the 
timer chip, the setvect() and 

getvect() calls of Borland C++ 
are used to set up the interrupt 
service routine. After the ISR 
has been installed, the routine: 


void interrupt 
segaISR::fastTimer(...) 


is called approximately every 100 
milliseconds. “fastTimer()” 
eventually calls 
“updateGloveData()”’, and the 
most recent glove data is made 
available to the application. It is 
important to note that if the 
glove data is not checked at least 
every 100 milliseconds, samples 
may be ignored, and if it is 
checked more than once in a 100 
millisecond period, the same data 
will be present. In order to 
prevent such problems, the 
following two functions have 
been provided: 


int gloveDriver::yield(Q); 
void gloveDriver::waitForSample(Q; 


“yield()” returns 1 if the glove 
data has been updated since the 
last call to “yield().” 
“waitForSample()” suspends the 
application until new glove data 
is received. A better approach 
would be for the ISR to place the 
glove data into a “queue” that 
can hold several samples. Then, 
if the application is busy with 
some other time consuming task, 
no samples are lost. It is not 
necessary to use the queue in 
every application, but some very 
important applications will 
require a queue. The queue will 
be implemented in a future 


release (which will also provide a 
sophisticated gesture recognition 
system). 


The ‘smooth’ class differs from 
cfGlove only when it updates the 
glove data. It provides some 
deglitching and hysteresis func- 
tions which “smooth out” the 
glove input slightly. These 
functions are controlled by 
parameters in glove.ini. For 
many systems, smoothing the 
input will have little or no effect 
on the sampled data. Perhaps 
better algorithms for improving 
the data quality can be imple- 
mented. The smoothing routines 
in O2GLOVE are attempts to 
compensate for improper setups. 
Most glitches and strange behav- 
ior can be eliminated by “soften- 
ing” any smooth hard surfaces 
that are in the room where the 
glove is being used. (See the file 
“helpme!.doc”.) 


The initialization system and the 
graphics demo are handled by 
“separate” systems. Variables 
that were previously stored in 
“#define’s are now read in from 
glove.ini. Using this method, it 
is easy to change the operating 
parameters of the program 
without recompiling it. An 
important point to remember 
about the initialization system is 
that it is not specific to 
O2GLOVE. By including 
“inl.cpp” in any project file, an 
application then has access to the 
same functions O2GLOVE uses 
to read values from an initializa- 
tion file. The InitFile class (and 
Its ancestors) have several 
desirable features. Refer to the 
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file “ini.doc” for more informa- 
tion on the initialization system, 
including how to use it and how 
it was designed. The graphics 
are handled primarily by the class 
graphicsActor. The most com- 
plicated part is the moving hand 
seen near the center of the 
screen. It is represented as a 
series of line segments which are 
scaled, translated, and rotated 
depending on the glove input. 
O2GLOVE was designed to be 
as modular as possible so that 
other applications can be built 
around it, and so that it can be 
spliced into existing applications 
with relative ease. 

Figure 1. shows the class 


hierarchy of the entire system. 
Each class is represented by a 


bubble with the class name inside. 


The solid lines with arrows 
indicate inheritance in the tradi- 
tional object oriented manner: 
the arrows point toward the 
ancestor and away from the 
descendant. For example, class 
cfGlove is derived from class 
gloveDriver. The dotted lines 
represent objects that are incor- 
porated into other classes. For 
example, class machineTimer 
includes an instantiation of class 
PZTimer, and class gloveDriver 
includes three instantiations of 
class machineTimer. It is hoped 
that the class hierarchy is helpful 


Figure 1: Class Hierarchy of O2GLOVE 
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Initiahzaton system 


Key 


in gaining a working knowledge 
of the system so that it can be 
adapted for more specific pur- 
poses. 


In summary, O2GLOVE 1s a 
program that provides a founda- 
tion for anyone wishing to utilize 
the Power Glove in application 
programming. The most obvious 
application for the glove is 
Virtual Reality, but there are 
certainly other uses. The under- 
lying driver is designed to be 
reused in other applications, so it 
is likely that the graphics demo 
seen in O2GLOVE will not be 
the last application to use the 
driver. |i 
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One common component in 
graphics is the circle. In this 

column, we investigate circle 

drawing routines. 


BACKGROUND 

A circle is defined by two 
components: a center point 
(cx,cy) and aradius R. Using 
these components, the equation 
of a circle is written: 


sqr(x-cx) + sqr(y+cy) = sqr(R) 


This equation 1s called the 
Pythagorean theorem. An 
algorithm for generating a circle 
with this equation is: 


Loop for x = cx-R to cx+R 
calculate y as 
yl=cy+sqrt(R2-sqr(x-cx)) 
y2=cy+sqrt(R2-sqr(x-cx)) 
plot (x,y1) 
plot (x,y2) 
endloop 


The program circlel.exe on the 
enclosed disk shows the circle 
generated 
using the 
above algo- 
rithm with the 
center at 
320,240 and a 
radius of 50. 

Notice that [-xy] 

the circle 1s 
not uniform. 
The gaps 
between the 
pixels at the 
top and 
bottom of the 
circle are 
smaller than 


[xy] 


the side gaps. This is obviously 
not acceptable. 


One solution to this gap problem 
is to interchange the y parameter 
for the x parameter when the 
slope of the circle becomes 
greater than 1. This, however, 
adds considerable computational 
time to the original algorithm. In 
addition we need to check the 
slope during each pixel plot. 


SPEEDUP 

We can achieve a considerable 
speedup in drawing a circle if we 
take into consideration the 
symmetry of a circle. Figure 1 
shows the realationship between 
points on a circle. 


If we are to plot a single pixel 
at coordinate location (x,y), 
Figure | shows the seven other 
positions that can be plotted by 
simply negating a coordinate 
and/or switching their order. 
This property adds a consider- 
able speedup to our original 
algorithm. 


yx} [y-x] 


><y] 


[<-y] 


-y.-x] — [y.-x] 


FIGURE 1 
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the Brensenham alogirhtm for 
line drawing. Figure 3 shows 
our measurements. 


Both this new algorithm and the 
old algorithm suffer from the two 
multiplications during each loop 
iteration and more importantly 
the square root calculation. In figure 3, the colored dots 
are the actual Y value of the 
circle at that particular X 
value. The problem is we do 
not have the ability to plot a 
pixel at that location. We can 
either put a pixel on top or on 
bottom of the actual position. 


BRESENHAM 

Just as the Bresenham line 
generating algorithm speeded the 
drawing of a line, the Bresenham 
circle generating algorithm 
speeds the drawing of a circle. 
Figure 2 shows a situation during The Bresenham alogorithm will 
the drawing of a circle. determine which distance 1s the 

so shortest. The equation for the 


- 
a 
Ps 
a 


xi xit+1 xi+2 





COCOONS 
PT ET EN TT 


FIGURE 2 





top distance is 
The next available pixel for the 

line is either (xi+1,yi) or 
(xit+ 1 yi-1) assuming that cx=0 or 
_andcy=0. We can find the 
actual y value by using the 
equation of a circle or the fol- 
lowing equation: 


distance = sqr(yi)2 - sqr(y) 


distance - sqr(yi) = sqr(R) + 
sqr(xit+1) 


The bottom distance is: 


distance2 = sqr(y) - sqr(yi-1) 
Or 
distance2 = sqr(R) - sqr(yi+1) - 
sqr(yi-1) 


sqr(y)=sqr(R)-sqr(xi+1) 


To determine the actual adjoining 
pixel, we measure distance as in 
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FIGURE 3 


Each of the second equations 
are generated by substituing for 
y2 defined in an equation above. 


If distance > 0 and distance2 < 
0 and distance - distance2 > 0 
then we plot ((xi+1),(yi-1)). This 
indicates that the top distance is 
greater than the bottom distance. 
If distance < 0, distance2 > 0, 
and distance - distance2 < 0 then 


we plot ((xi+1),(yi)). 


The final algorithm is 
generated by creating recursive 
definitions for the distances and 
pixels plotted. Because of the 
complexity and space needed, we 
will not define these routines 
here. Check any good graphics 
book for a detailed description. 


The final algorithm is: 


set r = radius 


set x = Cx 
set y=cytr 
set p = 3-2*r 


plot_points 
Loop for x < y 
if p<0 then p:= p+4*x+6 
else 
p:=pt+4 * (x-y) + 10 
y:=y-1l+cy 
end 
x=xt+1+cx 
plot_ points 
end 


The routine plot_points, takes 
the (x,y) coordinate and plots the 
eight different symmetrical points 
around the circle. The program 
circle2.exe on the enclosed disk 
draws a circle using the above 
algorithm. 


TIMINGS 

The timings for the two differ- 
ent algorithms were obtained by 
drawing 10000 circles with 
(320,240) as the center and a 
radius of 100. 


Algorithm Time (sec) 
Equation 83.65 
Bresenham $5.52 
RESULTS 


Wait a minute! The Brenseham 
algorithm is slower than the 
equation of a circle. If you 
examine the code in circle2.c, 
you will find eight calls to the 
routine putpixel. These calls are 
very costly to the entire algo- 
rithm. If converted to assembly 
langauge and bios calls used to 
plot the pixels, the algorithm 
becomes much faster than the 
equation algorithm. 


NEXT TIME 

In the next Graphics column, 
we will investigate area filling 
algorithms. |% 
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Fitts third article of the series 
on building a Virtual Racquetball 
game, we are going to look at 
designing our racquet, adding 
Powerglove support, and creat- 
ing the ability to grab the 
racquet. 


THE RACQUET 

One of the most serious prob- 
lems with REND386 and other 
PC based rendering software 
packages 1s the lack of a modeler 
program. While we can use 
programs such as Autocad and 
IRIT to create our objects, it 
would be nice to have a system 
that builds the object for us and 
return .plg or .fig code. For our 
racquet, we had to rely on the 
old fashion way of producing 
objects; pen and paper. The 
racquet consists of a single .fig 
file that contains a racquet head 


and a handle. 


The racquet was put into a 
figure file because we want to be 
able to grab it by its handle. If 
the racquet is a single object file, 
the collision detection routines in 
REND386 would use the center 
of the entire racquet at the 
collision point. For realism, we 
wanted to grab the racquet at the 
handle. By putting the racquet in 
the figure file, we can pull in the 
head part of the racquet and the 
handle separately. We also gain 
all of the benefits of figures such 
as movement and rotation. 


The racquet head is made up of 
38 polygons. There are 24 
polygons for the frame of the 
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racquet and 14 total strings. The 
handle is made up of 6 polygons. 


Before we begin anything with 
the racquet, we need to read it 
into our world. We do this with 
the function read_racquet. This 
function is almost identical to the 
read_ball function from the last 
column. The only difference is 
that we need to locate the handle 
object for collision detection with 
the virtual hand which we have in 
the world. We can locate the 
handle with the statement: 


handle = seg_get_ object ( 
find_segment_by_name(racquet_sge, 
“handle)); 


We first find the segment that is 
associated with the name 
“handle” and then pass it to the 
function seg get object which 
returns the actual object associ- 
ated with the “handle” segment. 


POWERGLOVE 
INTERFACE 

As in a real racquetball game, 
we grab our racquet with our 
hand and swing it. We can do 
the same thing in our virtual 
game by using the Mattel 
Powerglove. In this section we 
will investigate the procedure for 
adding the Powerglove to a 
REND386 program. Note that 
the procedure has changed from 
the third release of the develop- 
ment system. 


The concept we want to use is 
that of our own body. With this 
concept, we need to have some 
way to represent our eyes and 
our body. Our eyes will be 


simulated using the VIEW data 
structure that is required in all 
REND386 programs. Our body 
will be simulated by a segment 
called body seg. This segment is 
required by the REND386 
libraries that initialize the glove 
and hand figure. Attached to the 
body seg segment is a segment 
called wrist_seg which has a 
segment called glove_seg at- 
tached to it. All of these seg- 
ments are defined in the file 
CURSORS .C except for 
body_seg which we will define in 
our main progam. 


Before we actually initialzie the 
glove, we need to setup a few 
global variables required by the 
REND386 system. These vari- 
ables are: 


gpdname 
gpdo_ x 
gpdo_y 
gpdo_z 
gpdo_rx 
gpdo_ry 
gpdo_rz 
manip device 
menu_device 
gpcursor 
body_seg 


All of the global variables have 
a specific purpose when trying to 
initialize the glove. We will look 
at each individually. . 


gpdname - This variable is 
defined in the demo4 program as 
gpdname[40] = “pglove”;. The 
variable is used to indicate the 
name of the glove pointer device 
to be used when initialziing a 
glove pointer. By defining a 
name, different gloves can be 
interfaced to the system. 


gpdo_x - This variable defines 
the scaling value for the x direc- 
tional component of the glove. It 
is a float value and we set it 
equal to 2. 


gpdo _y - This variable defines 
the scaling value for the y direc- 
tional component of the glove. It 
is a float value and we set it 
equal to 2. 


gpdo z - This variable defines 
the scaling value for the z direc- 
tional component of the glove. It 
is a float value and we set it 
equal to 2. 


gpdo_rx - This variable defines 
the scaling value for the x rota- 
tional component of the glove. It 
is a float value and we set it 
equal to 1. 


gpdo_ry - This variable defines 
the scaling value for the y rota- 
tional component of the glove. It 
is a float value and we set it 
equal to 1. 


gpdo _ rz - This variable defines 
the scaling value for the z rota- 
tional component of the glove. It 
is a float value and we set it 
equal to 1. 


manip device - This variable 
defines the pointer device that 
will be used for any manuiplating 
in the program. This is specific 
to REND386 and we do not use 
it for this program but it must be 
defined. 


menu_device - This variable 
defines the pointer device that 
will be used for menus. This is 


specific to REND386 and we do 
not use it here but it must also be 
defined. 


gpcursor - This variable defines 
the name of the figure file that 
will be the cursor for the glove 
pointer device. In the case of the 
demo4 program and our pro- 
gram, we are using the hand.fig 
figure as our cursor. It is defined 
as gpcursor[40] = “hand”;. 


body_seg - This variable was 
described above and is defined as 
extern SEGMENT *body_seg;. 


Once these global variables 
have been declared and defined, 
we can initialize the glove. We 
will run through a list of steps 
that appear in the demo4 pro- 
gram: 


1) Assign body_seg a 
segment with a NULL parent: 


body_seg = new_seg (NULL); 


2) Set the scale for reading 
in the glove cursor pointer: 


set_readseg_scale (1,1,1 ); 


3) Call the function 
gloveptr_init, this function 
initialzes the glove and returns a 
PDRIVER handle. The scaling 
global variables defined above 
are sent to the function as well as 
the name of the glove device we 
want to initialize: 


PDRIVER *¢d; 

gd = gloveptr_init ( gpdname, 
gpdo_x*65536.0, gpdo_y*65536.0, 
epdo_7*65536.0, gpdo_rx*65536.0, 
gpdo_ry*65536.0, gpdo_rz*65536.0); 
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4) Set manip device and 
menu_ device to gd. This ap- 
pears to have no function in our 
program except for some pos- 
sible background function; 


manip device = menu_device = gd; 


5) Load the cursor for the 
glove device with the routine 
load glove cursor. 


if (gd) load_glove_cursor ( body_seg, 
manip device, gpcursor ); 


Once these steps have been 
completed, the glove is up and 
ready for action. Recall that we 
are trying to simulate a person in 
this virtual game therefore we 
need to position ourselves in the 
court. We have chosen to stand 
at the back wall facing the front. 
We do this by manipulating the 
body_seg segment. 


abs _move_segment ( body_seg, 
2250,800,-300); 


update_segment ( body_seg ); 


Since the hand cursor 1s at- 
tached to the body_seg segment, 
any movements to this segment 
will cause the hand to move as 
well. This is realistic because 
when we move our body, our 
hand moves proportionally. 
Now if you execute the program 
rb.exe on the enclosed disk, you 
will notice that the hand appears 
to be lower than where we are 
looking. This is because the eye 
position has been set several 
hundred units above the 
body seg segment position. This 
occurs in the court.wld file. 


Recall that we are planning to 


grab our racquet using the 
Powerglove. When we grab 
something with our human hand, 
we obviously use our fingers but 
we use the palm of the hand as a 
target area. If you grab a 
racquet in real life, the handle fits 
snuggly in the palm of the hand. 
For this reason, we need to track 
down the palm of the virtual 
hand. If you look in the hand _fig 
file, you will see that one of the 
segments in the hand is called 
palm. We can locate this seg- 
ment using the 

find segment_by_name func- 
tion. The function is used in our 
program as: 


palm = find_segment_by_name ( 
body_seg, “palm” ); 


The variable palm is a segment 
pointer. It will be given a pointer 
to the segment called “palm” 
located in the body_seg segment 


- tree. Once we have that segment 


located, we rotate it so that it is 
in a more realistic position with 
the statements: 


rel_rot_segment ( palm, OL, OL, - 
45*65536L, RZXY ); 
update_segment ( palm ); 


These statements rotate the 
palm along the Z axis. This has 
the effect of tilting the hand 
forward. The last step before we 
discuss collision detection 1s we 
need to have a pointer to the 
actual object associated with the 
palm segment. We can easily 
find this object with the function 
seg get object. We use the 
function as: 


palm_object=seg_get_object (palm); 
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‘where palm_ object is a pointer 
variable of type OBJECT. 


COLLISION DETECTION 
We need to discuess collision 
detection because we want to be 

able to pick up our racquet. 
Collision detection is somewhat 
simple in REND386 because the 
majority of the work is done 
behind the scenes. The 
REND386 library contains a new 
function called sphere_pretest. 
This function takes an object and 
a set of coordinates and returns 
the distance between them. If 
the distance is large, it returns 
214767832!!! otherwise it 
returns the distance. In our 
game, the racquet is stationary 
and the hand is moving around, 
therefore we will find the middle 
point of the handle and use it as 
the collision point. 


Each object in REND386 has a 
boundary sphere around it. The 
center of the sphere is basically 
the center of the object. We can 
get the coordinates of this point 
with the funciton 
get object bounds. We use this 
function as: 


rad = get_object_bounds ( handle, 
&x, &y, Kz ); 


The function returns the radius 
of the bounding sphere and puts 
the center point in the last three 
parameters. Note that the first 
parameter must be an object and 
not a segment. Now that we 
have the point of collision, we 
can begin testing for a collision 
between the palm object of the 
virtual hand and the center of the 














racquet handle. The code in our 
game to do this 1s: 


if (NO_RACQUET ) 

{ 
dist=sphere_pretest(palm_object,x,y,z); 
sprintf(buf,“Rac dist = Yold”, dist); 
prprint (2, 3, 15, buf ); 
if((dist<100)&&(gp.gesture—=-G_FIST)) 


f | 
attach_segment (RACQUET,palm); 
NO_ RACQUET =0; 


is 


The first thing we do 1s deter- 
mine if we have the racquet. If 
NO RACQUET is set to 0, then 
we already have the racquet. 
Since we are just starting, it will 
be set to 1. We determine the 
distance between the 
palm_object and the center of the 
handle with the function 
sphere pretest. This distance is 
displayed to the user with the 
prprint function from the demo4 
program. Then comes the real 
test. If the distance between the 
palm and the handle is less than 
100 units AND the current glove 
gesture is a fist, we are able to 
pick up the racquet. 


Now let’s back up. Everytime 
the glove is read, discussed 
below, the system tries to deter- 
mine the gesture the glove is 
representing. REND386 has 
several built in gestures one of 
which is a fist. Ifthe glove is ina 
fist position, gp.gesture will be 
equal to that value. All we have 
to do is test it. 


Now if we are making a fist, we 
must simulate grabbing the 
racquet. In REND386 this is 
done by attaching the racquet 
segment to the palm segment. 


The racquet will now go any- 
where the hand goes. We also 
need to set the variable 

NO RACQUET to 0 to indicate 
that we now have the racquet. 


RACQUET MOVEMENT 
Movement of the racquet and 
the hand is controlled by the 
position of the Powerglove. 
Once the glove has been setup 
and initialized, we can read its 
position with the funciton 
glove _update(); This function 
not only reads the position but 
automatically updates the 
body seg segment. All we need 
to do is perform an upadte with 
the funciton update segment. 
The code looks like this: 


glove_update ( manip_device, &gp ); 
update_segment ( body_seg ); 


The variable gp is declared as a 
POINTER. This function takes 
all of the hard work out of using 
the Powerglove. 


CONCLUSION 

We now have a racquetball 
court, a bouncing ball, a racquet, 
and a virtual hand. We can pick 
up the racquet and move around. 
The next step is to hit the ball 
and add SEGA 3D glasses 
support. The program rbmost.c 
and rbmost.exe on the enclosed 
disk 1s the complete game up to 
the point of this column. |i 
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4) Set manip device and 
menu_ device to gd. This ap- 
pears to have no function in our 
program except for some pos- 
sible background function; 


manip device = menu_device = gd; 


a) Load the cursor for the 
glove device with the routine 
load _glove_ cursor. 


if (gd) load_glove_cursor ( body_seg, 
manip device, gpcursor ); 


Once these steps have been 
completed, the glove is up and 
ready for action. Recall that we 
are trying to simulate a person in 
this virtual game therefore we 
need to position ourselves in the 
court. We have chosen to stand 
at the back wall facing the front. 
We do this by manipulating the 
body seg segment. 


abs_move_segment ( body_seg, 
2250,800,-300); 


update_segment ( body_seg ); 


Since the hand cursor 1s at- 
tached to the body_seg segment, 
any movements to this segment 
will cause the hand to move as 
well. This is realistic because 
when we move our body, our 
hand moves proportionally. 
Now if you execute the program 
rb.exe on the enclosed disk, you 
will notice that the hand appears 
to be lower than where we are 
looking. This is because the eye 
position has been set several 
hundred units above the 
body seg segment position. This 
occurs in the court.wld file. 


Recall that we are planning to 


grab our racquet using the 
Powerglove. When we grab 
something with our human hand, 
we obviously use our fingers but 
we use the palm of the hand as a 
target area. If you grab a 
racquet in real life, the handle fits 
snuggly in the palm of the hand. 
For this reason, we need to track 
down the palm of the virtual 
hand. If you look in the hand _fig 
file, you will see that one of the 
segments in the hand is called 
palm. We can locate this seg- 
ment using the 

find segment_by_name func- 
tion. The function is used in our 
program as: 


palm = find_segment_by_name ( 
body_seg, “palm” ); 


The variable palm is a segment 
pointer. It will be given a pointer 
to the segment called “palm” 
located in the body_seg segment 


- tree. Once we have that segment 


located, we rotate it so that it is 
in a more realistic position with 
the statements: 


rel rot_segment ( palm, OL, OL, - 
45*65536L, RZXY ); 
update_segment ( palm ); 


These statements rotate the 
palm along the Z axis. This has 
the effect of tilting the hand 
forward. The last step before we 
discuss collision detection 1s we 
need to have a pointer to the 
actual object associated with the 
palm segment. We can easily 
find this object with the function 
seg get object. We use the 
function as: 


palm_object=seg_get_object (palm); 
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‘where palm_object is a pointer 
variable of type OBJECT. 


COLLISION DETECTION 
We need to discuess collision 
detection because we want to be 

able to pick up our racquet. 
Collision detection is somewhat 
simple in REND386 because the 
majority of the work is done 
behind the scenes. The 
REND386 library contains a new 
function called sphere_pretest. 
This function takes an object and 
a set of coordinates and returns 
the distance between them. If 
the distance is large, it returns 
214767832!!! otherwise it. 
returns the distance. In our 
game, the racquet is stationary 
and the hand is moving around, 
therefore we will find the middle 
point of the handle and use it as 
the collision point. 


Each object in REND386 has a 
boundary sphere around it. The 
center of the sphere is basically 
the center of the object. We can 
get the coordinates of this point 
with the funciton 
get object_bounds. We use this 
function as: 


rad = get_object_bounds ( handle, 
&x, &y, &z ); 


The function returns the radius 
of the bounding sphere and puts 
the center point in the last three 
parameters. Note that the first 
parameter must be an object and 
not a segment. Now that we 
have the point of collision, we 
can begin testing for a collision 
between the palm object of the 
virtual hand and the center of the 
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The disk enclosed with Vol 2, Issue 1 of PCVR includes the following files: 
For the motion articles, the file runner.exe is a self-extractable executable file that produces the 
following files: 

runner.c runjoy.c runner. prj runjoy. prj tree2.plg 


epcotl.plg block. plg fir2.plg firl plg smblock. plg 
lamp.plg vd256.rvd rend386.cfg 


The files circle.c and circle2.c contain the source code for the algorithms described in the 
graphics column.. 


For the C++ object-oriented Powerglove driver, the file o21glove.exe is a self-extracting execut 
able file the produces the files for this interface. 


Note: Because of the size of the 02 glove interface code, executable files for the graphics column 
and the motion articles was not included. 


To compile the graphics programs, start Borland or Turbo C and pull the files into the environ 
ment and press ctrl-f9 to compile and execute the programs. 


To compile the motion programs, use the library and object files from the skeleton program in Vol 
1 Issue 5 of PCVR and the project files included with the source code. 
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FORMAT 

PCVR is growing. Last issue, we presented the new format and with this issue we bring both a 
new binding and a glossy format. During a phone conversation with a friend in Arkansas ( no, not Bill ), 
we got on the subject of bindings and printing of documentation. This friend has a complete production 
shop as well as a complete printing shop in his company. He mentioned that printing your own manual, 
catalog or magazine was a fairly simple process, just a few frustrating moments. 

So, we at PCVR began to investigate purchasing printing equipment. We should mention that up 
to this point, PCVR was produced on an HP Laserjet IIIP printer. For the sixth issue, we did an initial 
printing of two hundred issues. Thesetwo hundred issues took six toner cartridges, two cases of paper, 
and two cases of binders. The total printing time was approximately fifty hours. The duty cycle of the 
laser is eight thousand pages per month. We went over that just a little. Therefore, since PCVR is 
expanding at a rate faster than anticipated, we had to either have the magazine printed or purchase better 
lasers. 

In the end, we wanted to create a competitive magazine with advertisers and color, which is 
distributed on many newsstands. When we looked at taking the magazine to the printers, they wanted 
over $6 per issue. We decided to look at printing equipment. The first salesman I talked with said he 
could set us up with something for just under $30,000. Yeah right! Our last chance was used equip- 
ment. 

I am not a real good person about purchasing used equipment because I just know the thing will 
fail as soon as we start using it. With a little help from GOD, we found an AB DICK 360 press that a 
print shop owner had not used in years. The printshop needed to get rid of it in order to purchase a bigger 
machine for their shop. After negotiating the price and moving the press ( 600-700 Ibs. ) down a car- 
peted 45 degree sloping staircase, we began printing. The first experience was just that; an experience. 
But practice makes perfect, or near perfect. 

From now on, all PCVR issues will be printed on glossy paper. In the near future, we will add 
some color. Not true four-color but some spot coloring here and there. We welcome your comments 
about the direction that PCVR is going. This is your magazine. We are just trying to make it better for 
you. 


VPL 

As discussed in What's New, I cannot say I saw it coming but the signs were there. Maybe it's just 
as well since we need something other than head mounted displays and data gloves. There is a better way 
to get full VR immersion but we just haven't found it yet. Any ideas? 1 
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